Credit Card payments
1 Introduction
The system supports credit card payments. This functionality is dependant on individual credit card ‘brokers'. This document describes some general procedures as well as those specific to BucksNet.
Licence information
Note that Credit Card payments are not a standard part of the V-smart application. It requires a specific license and must be installed and activated separately. Please contact your account manager for pricing and installation information.
In the documentation below, we use the term “credit card” but this also includes debit cards (or any other mechanism supported by BucksNet).
When a borrower wishes to pay by credit card, the system identifies the total amounts owing, and simply passes this information to a secure Internet URL managed by Bucks Net Service Ltd. A unique URL is maintained for each library by BucksNet which corresponds to a web page with a look and feel configured to match the library's policies.
Clicking on the “Credit/Debit card payment” command icon (from within the online or
WebOpac), offers a screen that might look something like :
Once a borrower's card details have been entered, then these are validated, checked and the results – success or failure – are returned by Bucks Net to V-smart. The relevant charges are marked as paid, if successful.
2 Setup for Bucks Net
Two online forms are required –one for use from the WebOpac, the other for use from the main online system i.e. for staff use. These contain the fields shown above, as dictated by Bucks Net for input but there are probably some minor changes in layout for Web versus online use.
The setting up of these is handled in liaison with Bucks Net.
In addition, if multilingual input forms are required, then separate forms may be required for each language. An optional setting allows a language code, according to the current on-screen language, to be passed to BucksNet, such that a different “skin” is put on the screen's displayed by Bucks net.
There is an additional charge for setting up each Web input form, so one alternative is to define multi lingual wording on a single form i.e. instead of two forms, one of which asks for “Card number” and the other for “Numero de carte”, it might be easier to offer a single prompt “Card number/Numero de carte”.
3. Setup Parameters on V-smart
Parameters need to be set up for both staff interface and WebOpac.
3.1 Parameters in AFO 497
When the system is configured for Bucksnet, the following tabbed input form will be displayed when adding a new code in AFO 497 – Financial groups:
Tab General
Fields on the screen
Financial group code: enter an appropriate code.
Description: enter a brief description for each language.
Tab Bucksnet
Fields on the screen
Source for reconciliation file: The source of the incoming file for reconciliation reports.
Destination folder/directory: The reconciliation files from BucksNet are separated by storing / retrieving these in different folders or directories on the remote system.
URL: This setting determines which URL is opened against the BucksNet website to actually allow for the input of the credit card details.
Wording for credit/debit card receipt: This is the description which will appear on the printed receipt, and usually on the cardholder's card statement.
Schedule calendar: This should be a calendar (as defined in AFO 622) that can be used to schedule the running of the VAT report. The report aims to coincide with the reports from the bank on the actual payments made; however, such reports are not necessarily daily. Payments made over the weekend or on bank holidays are often grouped in a single report from the bank, so this calendar allows the library to link the reporting from the system with the reporting from the bank.
VAT export ftp script: Enter the name of a script which can be run automatically to send the output results to some other system. The maintenance of this script is external to Vubis and must be configured by the library.
Surcharge location and Surcharge account: If a surcharge is added to credit card payments, then these two fields define a notional location and account id for such charges.
Tab Receipt printing format
Fields on the screen
The “Receipt details required” options at the bottom of the form are used simply to enable or disable the itemised formats. If the formats are disabled then the regular simple payment total format will be used for receipts. If the option is enabled then the information shown in the other 4 sections on this form will be used to create the required receipt format.
Each of the 4 sections used for printing will be separated by a line of “-“ characters automatically.
The “Header” and “Footer” sections contain free format text sections and these will be simply output as entered. The “Header” and “Footer” named fields sections will be output as a 2 column table with the field name in the first column and the field value in the second column.
Named fields available in these sections are as follows
· <date> Payment transactions date
· <time> Payment transaction time
· <name> Borrower name
· <desc> Wording for credit card receipt (Bucksnet parameter)
· <borrower> Borrower barcode
· <receipt> Transaction ID
· <amount> Total payment amount (May also appear in details section)
The “details” section will be used to format the item level details that are printed on the receipt. There are 2 “types” of information in this section.
· Data alignment information.
A single line in the format =Xnnn=Xnnn=….=Xnnn=
Where
X is either L (left justified), R (right justified) or M (money amount field – right justified)
nnn column position for output value
· Data field names.
A single line in the format <field1><field2>…..<fieldN>
Where
<fieldN> is the field name of the value to be output in the corresponding position in the alignment definition.
Current field names available for use are
<itemcount> No of items covered by this transaction
<itemdesc> Item charge description
<itemcode> Item charge VAT code
<itemrate> Item charge VAT rate
<itemamount> Item total amount (including VAT)
The “summary” section will be used to format the subtotals and total details that are printed on the receipt. The same 2 “types” of information entered in the “details” section are also used in this section. The only difference being the field names used.
Current field names available in this section are
· <totalcode> VAT rate code
· <totaldesc> VAT rate description
· <totalrate> VAT rate
· <totalamountInc> Payment total inclusive of VAT
· <totalamountEx> Payment total exclusive of VAT
· <totalamountVat) Vat amount (calculated as <totalamountInc>-<totalamountEx>)
Tab Receipt screen format
The “Receipt screen format” parameters are handled in a similar manner even though there are only options to configure the layout for the “header” and “footer” sections of the layout. The item details and VAT summary sections are fixed and are applied to the receipt screen window display. This same receipt screen is used for the web browser receipt printing. The three option buttons that appear on the receipt screen when accessed via a staff PC will be in fixed positions at the bottom of the window display following the parameter driven sections. Only 2 option buttons will appear when the receipt screen is accessed via a web browser session. The print receipt option will be suppressed since only the print screen and close window options will be applicable.
In each of the formats the itemized charge description will be taken from the wording or charge type information shown on the financial group ifs code management screen accessed via AFO 497 – financial groups.
The number of items that make up this transaction may be output as part of the description if required by prefixing the <itemdesc> field with <itemcount>. The pair of values will then appear in the description column in a similar fashion as used on the transaction payments screen accessed from a borrower record.
3.2 WebOpac Preferences
An additional option in the User Activities setup in the WebOpac preferences allows the ability to pay by credit card to be turned on or off by Web “profile”.
4. Deciding on which URL to use
Within the system, the charges shown at any one time are for the borrower as a whole i.e. for the circulation meta-institution. However, in principle, the borrower may have overdue fines (for example) from actual institutions A and B. In this case, separate payments must be made for each organisation – it is NOT the location from which the payment is initiated that is important . It is the location of the transaction which determines the server page to be accessed on BucksNet.
The precise rules and parameters for this are defined in the Payments By Location specification.
4.1 Online System Payments
For staff initiated payments, the system aggregates the outstanding charges for each financial group. If there is more than one group associated, then a grid is shown
For example,
|
Nr |
Organisation |
Amount |
Note |
|
1. |
CamfordShire Libraries |
12.50 |
|
|
2. |
CamfordShire Schools Library Service |
4.25 |
CC payment not allowed |
|
3. |
No credit card payment available |
5.25 |
|
In this case, whilst a total of 22.00 is owed, 5.25 of this is associated with locations for which credit card facilities have not been assigned (line 3) and 4.25 is too small to be payable by credit card.
The “organisation” field is determined from the financial grouping used to aggregate the charge, via the table defined in section “Charges By Location” of the Charge By Location specification.
From this grid, specific valid lines may be chosen to initiate the payment.
If there is no ambiguity about the organisation concerned, then the accept credit card payment details screen is opened automatically.
A system wide option allows this rather complicated grid to be suppressed. In this case, the financial group associated with the patron's home location is used as the organisation to whom the payment will be made (see the section on Credit card payment limits and options).
4.2 WebOpac Payments
From the WebOpac, the subtleties of the previous section are too convoluted to explain or share with the borrower. In this case, if there are possible multiple destinations for the payments, then the payment URL associated with the patron's home location is used for ALL charges (and if no URL can be associated with the home location, then credit card payment will be disallowed).
Credit card payment may be initiated from the “User Activities / My account” screen - an example of which is shown above. An additional “Credit Card payments” button will be displayed if the Credit Card Payment Limits / In Use setting is “on”.
Clicking on the payments button may result in one of the following – the opening of the BucksNet URL (as determined by the rules in the previous section), or an error condition which may be one of
· The amount owing is too small to be paid by credit or debit card
· It is currently not possible to use credit card payments (if no URL could be determined)
· Please note that an additional charge of xx.xx will be charged for credit card payments. – followed by an additional option to accept or back out of the transaction.
Similar functionality will be available on the Deposits screen.
4.3 Payment from Online System
The option to pay by credit card is offered from AFO414/431 – Accept payment screen. An additional “credit card” icon may be offered.
The credit card option is only active if the total amount payable is greater than the minimum amount setting, configured according to Credit card payment limits (although it should be noted that in unusual circumstances credit card payments may still not be possible).
The system will then ask who is actually going to make the payment. Suppose, for example, that a borrower returns several overdue items on behalf of their family. In this case, the Accept payments screen may show several items borrowed by several different borrowers. Since it is necessary to pass some details across to BucksNet, so that an appropriate receipt may be printed, for example, the following form is displayed.
By default, the barcode of the first borrower on the accept payments screen is used, but any other borrower's barcode may be entered (and is validated). However, it is of course possible that the credit card holder is not even registered with the library. In this case, you may enter a name and email address manually into the fields in the bottom section. (Entering data into these field overrides any checking of the “barcode” field).
It is possible to cancel the payment operation at this point.
Once accepted (if appropriate) a Web page is opened with the address defined for the location of the charges.
It should be noted that any additional charge made for a card payment is displayed at the bottom of this screen.
4.3.1 Online Displays during payment processing
During this process, the outstanding charges are marked as “provisionally paid”. Since a separate browser window is opened, it is feasible that the borrower data is accessed separately by other online or WebOpac sessions.
In this case, all payment options are “frozen” and a message is displayed for each borrower shown on the Accept payments screen and also in the “Open amounts summary” screen in the WebOpac.
This may also occur if, for example, the processing against BucksNet was interrupted, for example by an Internet problem etc. Because of the security implications, this can only be “untangled” by a separate function – see the section on Repairing transactions in AFO 497 help.
4.4 Successful payment
The success of a payment is returned by BuckNet opening a Vubis Webpage.
The Webpage address is configured in the WebOpac and is the same for both staff and WebOpac functions.
The Webpage carries out two functions – firstly an acknowledgement by V-smart. The wording may be defined by the library- but would something to the effect that
Your online payment has been successfully processed.
with a “Close window” button to close the window.
In addition, the Web page processing marks all the relevant transactions as fully paid.
4.5 Failure
A failure Web page may also be opened by BucksNet to indicate that there was a problem.
In this case, a browser screen is opened to indicate failure. A reason for the failure is returned by BucksNet and will be displayed in the screen.
The marking of payments as provisionally paid is “undone” by the system.
AFO 497 allows you to extract reports on (failed) card transactions. AFO 497 also offers an option to repair failed transactions.
5. Borrower's financial and transaction history
A unique transaction id is allocated to any credit card payment. The “Borrower's financial history” list (and details screen) as shown below is updated to display this unique reference number.
Here is a sample output for a borrower
Note that there are five types of transaction :
· Credit card payment indicates that this user has started to make a credit card payment. As pointed out above – it should be noted that this is logged against the card holder (if registered with the library)
· Credit card pay submitted indicates that the processing against BucksNet started
· Credit card pay accepted indicates that the payment completed OK.
· Credit card pay failed indicates that the payment failed
· CardHolder payment failed logged against the cardholder.
If the payment was rejected (e.g. a bad credit card), then
is logged against the borrower for whom the charge is being paid. So there should always be
Credit card pay submitted, followed by
Credit card pay accepted OR
Credit card pay failed
Finally,
may also be logged against the card holder's transaction history. CardHolder payment successful is NOT logged.
Succesful payments are also logged in the borrower's payment history list – for example,
The card pay submitted, accepted and failed transactions are , logged against each borrower for whom the charges are made. In the above example, the borrower is paying for their OWN charges. “Credit card payment” and “CardHolder payment failed” are logged against the actual borrower (if they are registered) who is paying.
6. Payment of money into a deposit by credit card
Payment into a deposit by credit card is possible by selecting the “credit/debit card” payment method, assuming that this has been setup as a valid payment type for deposit.
In this case, it is not possible to add money into a deposit fund without the user actually paying for it. The user cannot “owe” the amount to be paid in. The workflow is slightly different therefore for such payments.
In this case, the system proceeds as for a regular credit card payment (asking for the details of the cardholder, and then connecting to BucksNet for the actual payment to go through).
On the client side (normally invisible to the staff user, since a Web Browser session will be in progress), the system is put into a “wait” state – waiting for the success or failure of the card transaction.
Once the transaction is completed, then the system will accept the credit card payment, or it will have been rejected. However in the event of a problem, pressing the Cancel command button will cause the following window to pop-up.
The system will assume that the payment was unsuccessful, but in fact it cannot know. The card holder may or may not have been debited with the amount requested.